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TECHNICAL FIELD 

This invention relates to an automated transaction machine architecture. Specifically this 
invention relates to a new cross-vendor software and hardware platform architecture for 
automated transaction machines. 

BACKGROUND ART 
Automated transaction machines are known in the prior art. Automated transaction 
machines are used to electronically carry out transfers representative of value. Automated 
transaction machines mclude for example, cash dispensers, ticket dispensers, scrip dispensers, 
gaming machines. Automated Teller Machines (ATMs) and other self service terminals. For 
purposes of convenience all such automated transaction machines will be referred to herein as 
ATMs unless otherwise specifically indicated. 
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ATMs may include various types of transaction function devices. These devices are 
operated to carry out transactions. Different types of ATMs include different types of devices. 
The different types of devices enable the ATM to carry out different types of transactions. For 
example, some types of ATMs include a depository for accepting deposits while other ATMs do 
not. Some ATMs have a "touch screen" while others have separate displays and input buttons. 
ATMs can also be fitted with devices such as cash and coin acceptors, statement printers, check 
vaUdators, bill acceptors, thumb print readers and other types of devices, while other ATMs do 
not include such devices. 

Many financial institutions wish to add new fimctionaUty to their existing ATMs. For 
example, a bank with ATMs for dispensing cash may wish to add a statement printer to each of 
the ATMs for printing a customer's banking statement. Such new fimctionality usually requires 
additional software modifications to the ATM in addition to the new hardware. Unfortunately 
the process of updating ATM software is typically compUcated by the fact that many financial 
institutions purchase ATM hardware firom more than one manufacturer. Thus to add new 
software for performing a new fimction such as printing banking statements, separate 
apphcations must be written or modified for each vendor specific ATM platform. Porting 
applications to multiple ATM platforms significantly reduces the productivity of the ATM 
software developers. Consequently, there exists a need for an architecture that enables 
developers to write ATM applications that work without modification on a plurality of 
proprietary ATM platforms. 

To achieve this goal industry standards are being developed which are designed to enable 
ATM hardware and software to be cross-vender compatible. One example of such a standard is 
WOSA/XFS (Windows Open Services Architecture/eXtensions for Financial Services) which is 



defined by the CEN/ISSS XFS standard committee. Figure 1 shows a schematic view of the 
standard WOSA/XFS architecture. An exemplary WOSA/XFS enabled ATM 110 may include a 
WOSA/XFS Manager 1 12. The WOSA/XFS Manager 1 12 includes a standardized interface to 
enable an ATM terminal apphcation 114 to communicate with ATM transaction function 
devices 1 16. Each transaction function device 116 includes a corresponding service provider 
interface (SP) 1 18. The SPs 1 1 8 are suppHed by the vendors of the ATM devices 1 16 and are 
specially designed to accept requests firom the WOSA/XFS Manager 1 12 and pass those requests 
on to the corresponding device 116. Theoretically the ATM terminal application 1 14 will be 
able to run on any vendor's ATM hardware 120 as long as both the ATM terminal application 
114 and the vendor's implementation of the SPs 118 adhere to the WOSA/XFS specifications. 

Another example of an emerging industrial standard for an ATM hardware/software 
architecture is J/XFS (Java / extensions for Financial Services). Unlike WOSA-XFS which is 
designed for Microsoft Windows® platforms only, J/XFS is a Java® based architecture that may 
be implemented on any hardware/software platform that supports a Java® Virtual Machine 
(JVM). As shown in Figure 2, a J/XFS enabled ATM 210 may include a J/XFS Kernel. The 
J/XFS Kernel is similar in fimctionality to the previously described WOSA/XFS Manager 1 12, 
however the J/XFS Kernel runs in a JVM 224. The J/XFS Kernel is operative responsive to 
commands fi-om an ATM terminal application 214 to have a device service layer 220 control the 
operation of ATM devices 216. Like the previously described SPs 18, the device service layer 
220 includes vendor provided device services 218 that correspond to the vendor's hardware 
devices 216. 

As with the WOSA/XFS architecture, the ATM terminal application 214 will 
theoretically be able to run on any vendor's ATM hardware as long as both the ATM terminal 



application 214 and the vendor's implementation of the device services 218 adhere to the J/XFS 
specifications. Unfortunately with each of these described architectures there are "grey" areas 
within the standards that are subject to vendor interpretation. Because of these "grey" areas 
some vendors have created WOSA/XFS SPs that work differently for the same type of device as 
another vendor's SPs. Also, some vendors have deliberately made modifications to portions of 
an SP interface or to its operation for reasons that are uniquely theirs. The consequence of this is 
that what is intended to be a cross-vendor ATM apphcation will most likely have to be modified 
or "tweaked" before it will truly operate with another vendor's SPs. 

For example the WOSA/XFS standard provides a number of different methods for having 
a card reader SP interface with a card reader for returning information read fi-om a card. These 
methods include a first method of passing individually selected information and a second method 
of passing all the card information in a single form. Although it would seem that an apphcation 
could use either method to retrieve card information firom any vendor's card reader, in reality one 
vendor's card reader SP may only support the first method, whereas a second vendor's card 
reader SP may only support the second method. These types of incompatibihties or differences 
in interpretation of the WOSA/XFS standard undermine the intended goal of cross-vendor 
compatibility between ATM applications and ATM hardware. 

Although the J/XFS architecture is just being developed it shares the similar WOSA/XFS 
architecture limitation of using device services that are vendor provided. As a result different 
vendor interpretations of the J/XFS specification have the potential of forcing developers to 
write modified versions of their ATM terminal applications for each vendor's ATM platform. 
Consequently there exists a need for an ATM architectixre that addresses tiiese deficiencies in the 



WOSA/XFS or J/XFS architectures, or any other ATM architecture that is subject to vendor 
interpretation for developing device drivers. 

hi general each of the previously described XFS architectures defines a standard for the 
lowest common denominator of ATM hardware features. Unfortunately by including only those 
features that are common to all ATM hardware devices, the XFS standards cannot include 
interfaces to unique features associated with a vendor's particular implementation of a 
transaction function device. One example of unique features that are not implemented in the 
XFS interfaces includes access to low level diagnostic testing of individual hardware 
components of a device. Such control over low level hardware functionality can be very useful 
when troubleshooting problems with a specific component such as a motor or sensor. 
Unfortunately as each vendor may mechanically and/or electronically construct a particular type 
of device completely differently than another vendor, the XFS standards have not attempted to 
implement methods for testing low level vendor specific hardware. Consequently there further 
exists a need for an XFS enabled ATM that offers low level diagnostic testing of ATM 
hardware. 



DISCLOSURE OF INVENTION 

It is an object of the exemplary form of the present invention to provide a cross-vender 
compatible automated transaction machine architecture. 

It is a further object of the exemplary form of the present invention to provide a cross- 
vender compatible automated transaction machine architecture that improves the ability of a 
single application to function properly on different ATM platforms. 



It is a further object of the exemplary form of the present invention to provide a cross- 
vender compatible automated transaction machine architecture with features for troubleshooting 
ATM hardware. 

It is a further object of the exemplary form of the present invention to provide a cross- 
vender compatible automated transaction machine architecture with features that simplify 
programming of ATM applications. 

Further objects of the present invention will be made apparent in the following Best 
Modes for Carrying Out Invention and the appended claims. 

The foregoing objects are accomphshed in one exemplary embodiment of the invention 
by an ATM that comprises a computer and a plurahty of transaction function devices in 
operative connection with the computer. The ATM further includes at least one XFS layer such 
as the WOSA/XFS Manager or the J/XFS kernel. In addition, the ATM includes a device driver 
layer that includes vendor provided device drivers such as the WOSA/XFS service providers or 
the J/XFS device services. The device drivers generally correspond to each of the transaction 
function devices and are responsive to contimands from the XFS layer to control the operation of 
the transaction function devices. 

The ATM further includes at least one terminal application and an Open Device Services 
(ODS) layer. The ODS layer includes a plurality of ODS components that generally correspond 
to the device drivers and/or transaction function devices. An ODS component is operative 
responsive to the terminal application to control at least one transaction function device through 
communication with the XFS and device driver layers. The ODS component layer is adapted to 
provide the terminal application with a consistent interface for communicating with vendor 



provided device drivers which may have inconsistent implementations for interfacing with the 
particular XFS layer. 

Li one exemplary embodiment the ODS layer is operatively programmed to communicate 
with device drivers from different vendors such that each of the corresponding transaction 
function devices operate the same. In another exemplary embodiment the ODS layer is 
operative to include ODS components that are exchangeable to correspond to different vendor 
implementations of a device driver for a particular type of transaction function device. For 
example if the ATM includes a card reader and a corresponding device driver from vendor A, 
the ODS layer is operative to include a first ODS component that is compatible with vendor A's 
device driver and card reader. If the card reader from vendor A is exchanged with a new card 
reader and corresponding device driver from vendor B, the ODS layer is operative to enable the 
first ODS component to be exchanged with a second ODS component that is compatible with 
Vendor B's device driver and card reader. Both the first and second ODS components include 
identical interfaces which are accessed by the terminal application in the same manner to have 
either vendor's A or Vendor B's card reader perform the same card reader functions. Regardless 
of whether the ODS layer includes an ODS component that corresponds to a first vendor's, a 
second vendor's or any other vendor's transaction function device, the terminal application is 
operative to communicate with the ODS layer to have any vendor's hardware perform the same 
functions. 

In an alternative embodiment of the present invention, the ODS layer is further operative 
to communicate with more than one XFS layer. For example an ATM may include both a 
WOS A/XFS Manager and a J/XFS Kernel with different sets of devices for each XFS layer. As 
discussed previously J/XFS is a Java® based architecture that may be implemented on any 



hardware/software platform that supports a Java® Virtual Machine (JVM). Examples of 
automated transaction machines that include a Java based architecture are found in U.S. 
AppUcation Serial No. 09/193,637 which is incorporated herein by reference in its entirety. 
Rather than developing a complex terminal application that must be specifically programmed to 
5 access different XFS layers, in the exemplary embodiment of the present invention, the terminal 
application only needs to be programmed to communicate with the ODS layer as previously 
described. The ODS layer is operative to route the terminal application commands through the 
correct XFS layer. Those devices that include WOS A/XFS service provider interfaces will have 
corresponding ODS components that are operative to communicate with the WOS A/XFS 

Qo Manager. Those devices that include J/XFS device services will have corresponding ODS 

components that are operative to communicate with the J/XFS Kemeh In a further alternative 
embodiment, each ODS component is operative to communicate with either XFS layer 

L depending on ODS configuration parameters which specify which XFS layer each ODS 

□ component should use to communicate with devices. 

Ri 5 To further simply the task of developing terminal application software, the exemplary 

H embodiment further comprises terminal element controls (TECs). TECs are high level 

programming objects that encapsulate much of the low level functions and structures needed to 
interact with one or more transaction function devices. TEC objects may be operatively 
configured in any object package that the terminal application designer prefers. Examples of 
20 operative object configurations for TECs include OCXs, Active X objects, COM object, 
JavaBeans, EJBs or any other object that can be integrated into a terminal apphcation. 

For example an interface to a card reader in the previously described XFS architecture 
includes a complex assortment of methods and structures that must be dealt with just to operate a 
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card reader and to read a card. Integrating this interface into a terminal application can require 
significant effort. An exemplary card reader TEC object of an embodiment of the invention 
provides a simplified interface that includes five methods: 1) enable the card reader; 2) read a 
card; 3) write a card; 4) return a card; and 5) retain a card. Exemplary TEC objects also include 
5 configurable parameters or properties such as the amount of time that a card should be presented 
to a customer before it is retained. 

With the described exemplary architecture, the terminal application can be programmed 
in any language or on any platform that can either directly access the ODS layer or that can 
incorporate TEC objects. In this manner a terminal application can be developed as a stand 
Qo alone Windows® application, a browser based application, Java® apphcation, or any other type of 
appHcation that is operative to incorporate TEC Objects. 

TEC objects of the exemplary embodiment are also operative to combine fimctions that 
U: span multiple devices. For example a card reader TEC may also interact with related hardware 

O such as a hght indicator to draw a customer's attention to the card reader. In addition the 
niS exemplary card reader TEC may also interact with a beeping device for signaling the customer to 
remove their card from the card reader. In a pure XFS application these simple actions would 
require low level coding to all three XFS interfaces that correspond to the card reader, 
sensors/indicators and sound device. In the exemplary embodiment the TEC objects are 
operative to interface with the previously described ODS layer. However, in alternative 
20 embodiments the TEC objects may be operatively programmed to access the XFS layer directly. 

In addition to enabling new terminal appUcations to be written for cross-vendor hardware 
compatibility, exemplary embodiments are operative to enable pre-existing proprietary terminal 
applications to run on another vendor's hardware. For example proprietary terminal control 
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software typically includes a plurality of proprietary drivers for controlling a plurality of 
different transaction function devices. When new devices are developed or improved the 
proprietary terminal applications are typically updated to include new proprietary drivers for 
controlling the new or updated hardware. In one exemplary embodiment of the present 
5 invention the proprietary terminal application software may be updated to indirectly access ATM 
hardware through the ODS layer rather than through the proprietary drivers. By accessing the 
ODS layer, proprietary terminal control software is operative to function on any vendor's 
hardware that is XFS enabled. 

hi another alternative embodiment of the present invention the device drivers such as the 
40 WOSA/XFS service providers or the J/XFS device services are adapted to include a diagnostic 
^ interface. The diagnostic interface provides external applications with access to specific low 
.j^ level features of the hardware that corresponds to the device drivers. For example a cash 

dispenser device driver may be adapted to include an interface for manipulating individual 
Q motors or sensors in the corresponding cash dispenser transaction function device. Such access 

nils is provided to apphcations independently of the XFS layer, hi an exemplary embodiment, a 
diagnostic application may be operatively programmed to access the diagnostic interfaces of a 
plurality of different device drivers. Such an exemplary diagnostic application may use the XFS 
layer to deactivate one or more devices from XFS communication. Once the devices have been 
taken off-line with respect to the XFS components, the diagnostic application may enable a 
20 programmer or service technician to directly access ATM hardware through the corresponding 
diagnostic interface for trouble shooting, repair and other maintenance purposes. 
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BRIEF DESCRIPTION OF DRAWINGS 
Figure 1 is a schematic view representative of a WOSA/XFS enabled ATM. 
Figure 2 is a schematic view representative of a J/XFS enabled ATM. 
Figure 3 is a schematic view representative of an exemplary XFS enabled ATM. 
5 Figure 4 is a schematic view representative of an exemplary terminal application that 

includes an exemplary card reader TEC to interact with exemplary ODS components. 



BEST MODES FOR CARRYING OUT INVENTION 
Referring now to the drawings and particularly to Figure 3, there is shown therein a 
D schematic view representative of an exemplary embodiment of a cross-vendor ATM architecture 
^0 20 for the present invention. Here the ATM architecture 20 includes an computer 22 that is in 
operative connection with a plurahty of transaction function devices 42. Such transaction 
function devices may include for example such devices as a note dispenser, coin dispenser, card 
p reader, printer, key pad, display device, function keys, depositor, cash acceptor or any other 
Rl hardware device that may be operatively connected to an ATM. 

= 5 

H 5 The computer 22 includes a software components including terminal application 24 that 

is operative to control the operation of the transaction function devices 42. The computer 22 
further includes an XFS layer 28 that corresponds to a multi-vendor supported interface for 
ATM devices such as the WOSA/XFS Manager or the J/XFS Kernel. In addition, the computer 
22 further includes a device driver layer 30 that includes a plurality of device driver components 
20 38 that correspond to the XFS layer. For example if the XFS layer corresponds to the 

WOSA/XFS Manager, the device driver components 38 correspond to the WOSA/XFS service 
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provider interfaces. If the XFS layer corresponds to the J/XFS Kernel, the device driver 
components 38 correspond to the J/XFS device services. 

For each transaction function device 42, a device driver 38 must be installed in the 
computer that is operative to enable commands passed through the XFS layer 28 to control the 
5 operation of the transaction function devices 42. In one exemplary embodiment the device 

drivers 38 are manually installed from a portable physical media such as a disk or CD supplied 
by the manufacture of the device. In another exemplary embodiment the device drivers are 
operatively downloaded from a data store of device drivers that is in operative connection with 
the computer. In a further exemplary embodiment the device drivers are retrieved by the 

-Jo computer 22 from the transaction function devices 42 themselves using a service configuration 
protocol such as Sun Microsystems JINF'^ or Microsoft Universal Plug and Play™. 

J Each of the device drivers 38 are operative responsive to the XFS layer 28 to have at 

least one transaction function device 42 perform a function. For example a card reader device 

D driver is operative responsive to a read card request from the XFS layer 28 to have its 

in 

[l| 5 corresponding card reader device physically read information from a card and return the 
f information through the XFS layer. Another device driver such as a note dispenser device driver 
is operative responsive to a dispense request from the XFS layer 28 to have its corresponding 
cash dispenser dispense an amount of notes. 

In the exemplary embodiment of the present invention the terminal application 24 is 
20 operative to control transaction function devices 42 through communication with the XFS layer 
28, However, rather than having the terminal application 24 communicate with the XFS layer 
directly, the exemplary embodiment includes an ODS layer 26 operative in the computer 22 
between the terminal application 24 and the XFS layer 28. The ODS layer 26 is operative 
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responsive to the terminal application 24 to control the functionality of transaction function 
devices 42 through communication with the XFS and device driver layers 28 and 30. The ODS 
layer 26 includes a plurahty of ODS components 36 that generally correspond to the device 
drivers 38 and/or the transaction function devices 42. For example the exemplary embodiment 
5 of the present invention may include a card reader ODS component that corresponds to a card 
reader device driver for a card reader. An exemplary embodiment of the present invention may 
also include a note dispenser ODS component that corresponds to a note dispenser device driver 
for a note dispenser. 

When device drivers from two or more vendors generally communicate with the XFS 
y 0 layer in a consistent manner, a single ODS component may be used when either of the drivers 
S2 are installed in the ATM. However, if the vendor specific device drivers implement 

communication with the XFS layer in a different maimer, vendor specific ODS components may 
be operatively programmed for each of the vendor specific device drivers. A vendor specific 
0 ODS component may then be installed in the ODS layer responsive to whichever vendor specific 

nll5 device driver is installed in the ATM. The vendor specific ODS component is operative to 
^ communicate through the XFS layer in a manner that is appropriate for the particular 

implementation of the vendor specific driver. 

Although each vender specific ODS component may communicate with the XFS layer in 
a different manner, all of the vendor specific ODS components for a particular type of device 
20 share a common interface for access by external applications such as the terminal application 24, 
The ODS layer 26 is thus operative to isolate the inconsistencies in communication between 
different device drivers, and to present the terminal application 24, or any other application, with 
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a common set of methods, properties and events for communicating with transaction function 
devices from different vendors. 

The present exemplary form of the invention encompasses a testing process that is 
operative to identify unique characteristics and/or inconsistencies in a vendor's implementation 
of a device driver and to operatively adapt ODS components to include those features that are 
necessary to properly and consistently communicate with the device driver through the XFS 
layer. 

hi general the testing process includes the configuration of the particular vendor's 
hardware device and corresponding device driver on an XFS enabled test platform. The test 
platform typically includes a computer system with an XFS layer and an ODS component that 
corresponds to the particular type of the vendor's device. For example if the particular device 
being tested is a note dispenser, an ODS component that corresponds to an XFS device driver for 
a note dispenser is installed in the test platform. 

The test platform further includes a testing application. The testing application is 
operative to interface with the ODS component and issue a plurality of commands through the 
ODS component to control the operation of the vendor's device. A user may monitor and/or 
interact with the device and the test application to determine which functions of the device may 
or may not work properly with the ODS component. 

For example when testing a card reader the testing application enables a user to issue a 
command to the ODS component to have the device read a card. The testing application is 
further operative to output to the user the results of the operation. If the operation appears to 
work correctly, the testing application may display the contents of the information read from the 
card. A user may then verify that the contents are correct. If the operation failed, the user may 
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evaluate the error messages that are generated. In addition if the operation triggers an 
unexpected event through the XFS layer, the testing application is further operative to report 
what events have been triggered as a result of the operation. 

hi addition to monitoring the testing application, the user may also monitor the actual 
device to determine if the operation produces the correct function. For example if the device 
corresponds to a note dispenser, the testing appHcation may include an operation to dispense a 
certain amount of cash or number of notes through communication with a cash dispenser ODS. 
By monitoring the cash dispenser the user can determine if the correct amount of cash was 
dispensed, for example. After functional problems between the current ODS component and the 
device have been identified, the ODS component may be operatively modified to compensate for 
the idiosyncrasies associated with the vendor's implementation of the device driver. The 
modified ODS component may then be further tested on the testing platform to either uncover 
further inconsistencies or to certify that the ODS component works properly. Once an ODS 
component has been certified, it may be installed in any ATM that includes the tested vendor's 
device, device driver and corresponding XFS layer to enable a terminal application to properly 
control the device's functionality. 

hi the exemplary embodiment the terminal appUcation 24 may be based on any 
programming architecture that is operative to commimicate with the ODS layer 26. In one 
exemplary embodiment the terminal apphcation may be a stand-alone, Windows®-based 
application. In an alternative exemplary embodiment the terminal application may include a 
browser and a plurahty of web page documents. In another exemplary embodiment the terminal 
application may be a Java® application that is operative in a Java Virtual Machine (JVM). 
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In addition the ODS layer may be based on any programming architecture that is 
operative to communicate with the XFS layer 28. For example if the XFS layer corresponds to 
a J/XFS Kernel nmning in a JVM 48 of the computer 22, the ODS components may be 
constructed as Java Beans that are operative in the JVM. If the XFS layer corresponds to the 
5 WOS A/XFS Manager, the ODS components may be constructed as a plurality of Windows® 

based DLLs. If portions of the XFS layer and/or terminal apphcation are both Windows® based 
and Java® based, the ODS layer may include components operative in the JVM and components 
operative as DLLs. In other embodiments, the ODS layer and terminal application may be 
configured as other types of applets, modules or libraries which are appropriate for the operating 
y 0 system architecture and the XFS layer. 

S To enhance the productivity of programmers who develop a terminal application, the 

bji exemplary embodiment of the present invention comprises the integration of transaction element 

components (TECs) 34 with the terminal apphcation 24. TECs are objects or classes such as 
O ActiveXs or Java Beans that encapsulate the complex operation of one or more transaction 

PI 5 function devices 42 into a package of streamlined methods, properties and events. The TEC 
objects include the necessary functionality to communicate with the ODS layer. In the 
exemplary embodiment an entire terminal application can be constructed from TEC objects. 
Although the ODS components 36 may generally have a one to one relationship with 
corresponding device drivers 38 and/or transaction function devices 42, the TEC objects 
20 combine logical groupings of functions for different devices resulting in the TEC objects having 
a generally one to many relationship with ODS components. 

Figure 4 shows an exemplary terminal application 50. The terminal application includes 
a card reader TEC 52. The application 50 is operative to invoke methods 54 of the card reader 
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TEC 52 such as enable card reader, read a card, write a card, return a card and retain a card. The 
apphcation 50 is further operative to set properties 56 of the card reader TEC 52 such as the time 
out value before a card is returned by the card reader. In addition, the application is further 
operative to monitor one or more events 58 that are triggered through the card reader TEC. 

The exemplary card reader TEC 52 is operative to communicate with three different 
hardware devices including a card reader device 60, a lead through indicator device 61 and a 
beeper device 62, The exemplary card reader TEC 52 interfaces with these devices through 
communication with three corresponding ODS components including a card reader ODS 63, an 
indicator ODS 64 and a beeper ODS 65. 

Through communication with the card reader ODS 63, the card reader TEC 52 is 
operative to have the card reader device 60 perform a plurahty of functions such as enabling the 
card reader, reading a card and returning the card to a customer. The card reader ODS 
communicates with the card reader device through the XFS layer 68 and the card reader driver 
67. When enabling the card reader, the exemplary card reader TEC 52 is further operative to 
automatically activate a lead thru indicator light 61 to draw a customer's attention to the card 
reader 60. This is performed by communicating with a sensors and indicators device driver 66 
through interaction with the indicators ODS 64. In addition, when a beeping sound is desired to 
signal the customer to remove their card, the exemplary card reader TEC 52 interacts with the 
beeper ODS 65 to have the sensors and indicators driver 66 activate the beeper device 62. The 
exemplary TECs of the present invention are operative to combine device interaction in a logical 
manner by communicating with more than one ODS component and corresponding devices in 
response to various methods of the TEC being invoked. 
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In addition to enabling the generation of cross-vender compatible terminal applications 
that either include TEC objects, or that are operative to interface with the ODS layer directly, the 
exemplary embodiment of the present invention encompasses adapting pre-existing and 
proprietary terminal control software of one vendor to run on another vendor's ATM hardware. 
Such proprietary terminal control software typically communicates with a plurality of 
proprietary device drivers directly without accessing a middle layer interface such as the 
previously described XFS layers. Consequently proprietary terminal control software has 
previously been limited to running only on a specific vendor's hardware platform. However, the 
exemplary embodiment of the present invention is flirther operative to enable such proprietary 
software to properly control another vendor's transaction fimction devices when installed on 
another vendor's ATM platform. This is achieved by adapting the proprietary software to 
conamunicate with ODS components rather than proprietary device drivers. Once the proprietary 
terminal control software has been so adapted, the software is operative to run on another 
vendor's ATM platform that includes an XFS layer and corresponding XFS compatible device 
drivers. 

As shown in Figure 3, the exemplary XFS compatible device drivers 38 of an exemplary 
form of the present invention may further include diagnostic interfaces 40 in addition to their 
interfaces with the XFS layer 28. The diagnostic interfaces 40 include additional low level 
hardware control fimctions that may be accessed by external applications. The low level 
functions for example may access specific motors, sensors and other components in the 
corresponding transaction fimction devices 42. By employing a diagnostic application 44 to 
access these low level functions of the device drivers 38 directly, individual mechanical and 
electronic fimctions specific to the device can be tested, analyzed and possibly corrected. 
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In a further exemplary form of the present invention, the diagnostic interfaces 40 of the 
device drivers 38 may include an authentication system which is operative to validate that the 
appUcation attempting to access the low level functions of the device is authorized to do so. hi 
one exemplary embodiment of the authentication system, the diagnostic interface 40 is operative 
to detect that a valid hardware device such as a dongle is in operative connection with the ATM 
before an external application is granted access to the transaction function device 42 through the 
diagnostic interface 40, 

hi an alternative exemplary embodiment of the authentication system, the diagnostic 
interface 40 is operative to detect whether a valid hcense key is present. Such a license key for 
example may be located on a removable media in operative connection with the ATM such as a 
floppy disk, CD, magnetic stripe card, smart card, or any other portable medium that the 
diagnostic interface is operative to access through the machine. The license key may also be 
associated with the specific application such as the diagnostic application 44 that is operatively 
programmed to access the diagnostic interfaces of device drivers 38. Communications from the 
diagnostic appUcation may be required to include a vahd license key before the diagnostic 
interface enables the diagnostic appUcation to access the transaction function device. 

In a further exemplary embodiment of the authentication system, the diagnostic 
interfaces 40 may include a secret password or digital certificate which may be used by the 
diagnostic interface to determine if an application is allowed access to functions of a 
corresponding transaction function device. For example, a diagnostic interface of a device driver 
may require communications from a diagnostic application to be digitally signed. The 
diagnostic interface may then authenticate the digital signature associated with the 
communication using one or more digital certificates and/or public keys stored in operative 
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connection with the diagnostic interface. When the digital signature is vaUd, the diagnostic 
interface is operative to enable the diagnostic application to access the transaction function 
device through the diagnostic interface. When the digital signature is determined to be invalid, 
the diagnostic application is denied access to the transaction function device by the diagnostic 
interface. 

In a further exemplary embodiment, the diagnostic apphcation may be required to send a 
vahd digital certificate to the diagnostic interface prior to being granted access to the transaction 
fimction device. The digital certificate may be validated by the diagnostic interface using a 
trusted pubUc key of a certificate authority that issued the digital certificate. The digital 
certificate may also be evaluated by the diagnostic interface to determine if it has expired. When 
the digital certificate has expired or is otherwise invahd, the exemplary embodiment of the 
diagnostic interface may be operatively programmed to return a message to the calling 
apphcation which indicates that the digital certificate is not valid and access to the transaction 
function device is denied. La further exemplary embodiments of the present invention other 
software and/or hardware encryption and/or authentication systems maybe combined with the 
diagnostic interfaces of the device drivers to enable the selective validation of users and/or 
applications attempting to access transaction function devices through communication with the 
diagnostic interfaces of device drivers 

The exemplary embodiment of the present invention fiirther comprises a terminal 
Manager 46. The terminal Manager 46 is a software application that is operative to configure 
and manage the ATM through interaction with the ODS layer. In addition to the terminal 
Manager 46 and the terminal application 24, the ODS layer 26 is operative to enable any 
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application that can access ODS components to be operative on a plurality of different XFS 
enabled ATM hardware platforms. 

Thus the exemplary form of the cross-vendor automated transaction machine architecture 
of the present invention achieves at least one of the above stated objectives, eliminates 
difficulties encountered in the use of prior devices and systems, solves problems and attains the 
desirable results described herein. 

Li the foregoing description certain terms have been used for brevity, clarity and 
understanding, however no unnecessary limitations are to be impUed therefrom because such 
terms are used for descriptive purposes and are intended to be broadly construed. Moreover the 
descriptions and illustrations herein are merely examples and the invention is not limited to the 
exact details shown and described. 

In the following claims any feature described as a means for performing a function shall 
be construed as encompassing any means known to those skilled in the art to be capable of 
performing the recited function, and shall not be limited to the features and structures shown 
herein or mere equivalents thereof 

Having described the features, discoveries and principles of the invention, the manner in 
which it is constructed and operated, and the advantages and useful results attained, the new and 
useful structures, devices, elements, arrangements, parts, combinations, systems, equipment, 
operations, methods and relationships are set forth in the appended claims. 
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